Resolving Configuration Conflicts

On rare occasions, conflicts can arise if you change the Dual Staffing configuration after Appliance sets have been created.

There are two sources of conflict:

  1. Removing Dual Staffing from a class of vehicle which has already been saved in an Appliance set as Dual Staffed;
  2. Defining Dual Staffing for a class of vehicle which has already been saved in an Appliance set as being available on some other shift.

This conflict will be detected and reported when an affected Appliance Set is used in either of the modelling commands (Turnout or Predict).

If the Appliance Set contains conflicts caused by case 1, you will see this error message:

If this arises the model cannot be run as the availability of the special request vehicles is not defined.

If the Appliance Set contains conflicts caused by case 2, you will see this error message.

In this case, you can:

  1. Run the model with the affected vehicles being dual staffed
  2. Run the model using the shifts defined in the Appliance set – (this allows a model to be run as it was before the dual staffing was configured)
  3. Cancel the command so the Appliance Set can be edited to remove conflicts.

If you attempt to edit an Appliance Set with dual staffing conflicts, you will be prompted to save the resource set.

An extreme example of an Appliance Set with Dual Staffing rule conflicts is shown below.

In the above:

  • The ‘Hazmat..’ appliance was on shift ‘# Dual Staffing #’ but in the dual staffing rules currently configured there is no longer any vehicle class set up to do this.
  •  So it will be necessary to either:
    • Select a ‘regular’ shift  for Hazmat, e.g. ‘Whole Days’
    • Change the dual staffing rules to define what vehicle class(es) can be used to mobilise the Hazmat. (See the example in the Special Request Vehicle Dual Staffing dialog, shown previously).
  • The ‘Support..’ appliance had been on a regular shift but is now dual staffed.  If this Appliance Set is saved then the ‘Support..’ will have its shift set to ‘# Dual Staffed #’ and so an orange highlight is used to draw attention to what would otherwise be a ‘hidden’ edit.

In Model Output

When a Turnout model is run the output is written to two tables, e.g. for a model called ‘test’:

  • tblMO_test – the assignments of appliances to the incidents / callouts
  • tblMR_test – the list of appliances and where they were based.

A new column - DualStaffedBy - has been added to the first of these (the callouts).

This means it is possible to delve into a model’s output, if desired, to determine for any special request vehicle callout which appliance actually dual staffed it.